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Design  and  Inplenentation  of  Structural  Descriptions 

One  of  the  significant  features  of  KLONE  as  a representation 
language  is  its  facility  for  expressing  structural  interrelations 
among  the  conceptual  subparts  of  an  object,  activity,  or 
relationship.  These  interrelations  are  expressed  as  a set  of 
"parameterized"  relational  and  functional  Concepts  grouped  together 
into  structures  called  Structural  Descriptions  (SDs) . Our  abstract 
description  of  KLONE  has  included  SDs  from  the  beginning  (see 
[Brachman,  19781  and  (Woods  and  Brachman,  1978])  - in  this  quarter 
we  have  completed  the  design  and  coding  of  a set  of  INTERLISP 
functions  to  support  their  use  in  our  language  understanding 
system.  This  report  presents  the  set  of  functions  available  to 
build,  manipulate,  query,  and  remove  SDs.  First  we  shall  discuss 
SD  structure  and  its  relation  to  Concept  structure,  highlighting 
new  features;  then  we  shall  present  the  complete  set  of  functions 
with  brief  descriptions  of  their  parameters,  values,  and  operation. 
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I.  SD  Structure 

A KLONE  Generic  Concept  may  have  any  number  of  SDs . An  SD  is 
indicated  graphically  as  a diamond,  to  distinguish  it  from  a Role, 
the  other  salient  Concept  subpart  type.  At  the  moment,  there  is 
only  one  type  of  SD  (generic),  and  therefore  only  one  type  of 
Concept-SD  eplink  (see  [Woods  and  Brachman,  1978]).  Further,  only 
Generic  Concepts  have  SDs,  although  this  will  probably  change  once 
we  understand  the  significance  of  relations  among  Instance  Roles  in 
Individual  Concepts.* 

One  of  the  new  features  of  the  SD  package  is  the  ability  to 
name  SDs.  Each  SD  may  have  attached  to  it  a single  user-specified 
atom,  which  is  not  constrained  to  be  unique  to  that  SD.  Since  an 
SD  is  intended  to  group  together  a set  of  relationships  that  are  to 
hold  among  the  fillers  of  the  Concept's  Roles,  an  SD  name  can  be 
used  to  suggest  the  intent  of  the  particular  set  of  relationships. 
While  KLONE  itself  makes  no  use  of  these  names  whatsoever,  a user's 
program  may  take  advantage  of  the  facility  to  activate  (i.e.,  to 
check  as  a predicate  or  to  derive  a Role  filler)  SDs  of  similar 
purpose  (i.e.,  with  the  same  name).  Just  as  Role  names  are 


* We  expect  to  add  particularized  SDs  For  Individual  Concepts  in 
the  next  version  of  the  system. 
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supported  by  the  system,  but  not  used  by  it,  SD  names  hold  no 
epistemological  significance,  but  may  be  used  by  higher-level 
functions  to  group  SDs  for  recognition,  inference,  etc. 

An  SD  of  a Generic  Concept  schematically  expresses  how  the 
role  fillers  in  an  individuator  of  that  Concept  go  together  by  way 
of  a set  of  Para Individuals.  A Paralndividual  is  a parameterized 
version  of  a Generic  Concept,  unique  to  the  Concept  in  whose  SD  it 
appears.  It  does  not  generally  specify  particular  fillers  for  the 
Roles  of  the  Generic  (i.e.,  Individual  Concepts),  but  instead 
"coreferences"  Roles  of  its  parent  with  Roles  of  the  Concept  in 
which  it  is  used.*  For  example,  in  Fig.  1,  we  have  the  Generic 
Concept  ARCH  with  a single  SD  called  REQUIREMENTS.  This  SD  has  two 
Paralndividuals,  both  derived  from  the  Generic  Concept  SUPPORT.  SI 
coreferences  the  supporter  Role  of  SUPPORT  with  the  left-upright 
Role  of  ARCH,  through  the  use  of  a Coref  Role.**  This  means  that, 
for  every  individuator  of  ARCH,  there  must  exist  an  individuator  of 


* This  is  sim ilar  to  a function  call  embedded  within  a function 
definition  in  LISP:  the  embedded  (parameterized)  call  may  have  its 
arguments  depend  on  the  arguments  of  the  enclosing  function. 
Those  arguments  are  bound  only  when  the  enclosing  function  is 
called  (i.e.,  individuated). 

**  The  Coref  Role  has  a Coref Satisfies  link  to  its  parent  Role  (in 
this  case  the  supporter  Role  of  SUPPORT),  and  a CorefVal  link  to 
the  Role  from  which  the  value  is  to  be  derived  (left-upright 
here).  This  pair  of  links  parallels  closely  the  Satisf ies/Val 
pair  for  Instance  Roles,  and  performs  the  equivalent 
"parameterized"  function. 
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SUPPORT  whose  supporter  Role  is  to  be  filled  by  the  filler  of  the 
left-upright  Role  of  that  ARCH.  Since  SI  also  establishes  a 
coreference  between  the  supported  Role  of  SUPPORT  and  the  lintel 
Role  cf  ARCH,  SI  thus  requires  for  any  ARCH  that  its  left  upright 
supports  its  lintel.  Similarly,  S2  states  that  each  ARCH  must  have 
its  lintel  supported  by  its  right  upright  as  well.  In  these  cases, 
the  Concept  SUPPORT  is  not  considered  to  be  in  the  'scope'  of  the 
SD  - it  has  independent  existence  and  can  be  referenced  by  other 
Concepts  in  the  network.  However,  SI  and  S2  are  unique  to  ARCH, 
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and  are  not  usable  from  outside,  since  their  Roles  depend  on  Roles 
of  ARCH.  In  a sense,  they  are  'parameterized'  by  ARCH  - for  each 
individual  ARCH,  their  values  are  uniquely  determined  (note  the  use 
of  "its"  above  in  describing  SI  and  S2)  . 

In  many  c'ses,  a Para Ind iv idual  will  have  to  access  a subpart 
of  an  object.  For  example,  say  we  wish  to  express  that  the  name  of 
an  ARCH  is  the  same  as  the  last  name  of  the  PERSON  that  the  ARCH  is 
named  after.  In  the  configuration  of  Fig.  2,  the  obvious 


Fig.  2.  Subpart  access. 
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connection  would  be  from  the  Coref  Role,  X,  to  the  Role  for  the 
last  name,  Y.  However,  a single  CotcfVal  pointer  would  not 
suffice:  if  any  other  PERSON  or  NAME  were  associated  with  ARCH,  it 
would  be  impossible  to  tell  which  one  was  intended  (for  example,  if 
ARCHes  have  builders,  as  in  Fig.  2,  a direct  pointer  to  Y would  not 
suffice  to  distinguish  the  builder's  name  from  the  named-Af ter ' s 
name)  . 


The  problem  here  is  that,  while  Roles  are  unique  and 
distinguishable,  their  V/R's  can  be  shared.  Thus,  a Role  really 
has  an  implicit  Para Ind iv id ua 1 (i.e.,  for  the  unique  Role  filler), 
and  the  V/R  pointer  to  a Generic  Concept  is  an  abbreviation  (to 
save  the  construction  of  a new  Concept) . There  are  two  possible 
solutions  to  the  ambiguous  reference  problem  we  might  entertain: 
one  is  to  provide  an  explicit  Para  Ind  iv  id  ual  for  each  Generic  Role, 
the  other  to  allow  a special  kind  of  access  link.  In  the  current 
implementation,  we  have  opted  for  the  latter,*  providing  what  we 
call  a " Focus/SubFocus  chain"  or  "Role  Path".  Fig.  3 illustrates 
such  a link  in  the  "namedAfter"  case.  In  this  case,  the  CorefVal 
pointer  points  to  a structure  which  starts  at  a Role  of  the 
enclosing  Concept  (namedAfter),  and  walks  down  a chain  of  subpart 
Roles  (name,  lastName) . This  chain  uniquely  identifies  the 

* wi  are  cons ider irig  allowing  the  former  Fn  cases  where  Tt  Ts 
needed.  A decision  on  this  will  be  reported  in  the  next  QPR. 
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intended  subpart,  the  lastName  of  the  nane  of  the  namedACter  of  the 
ARCH.  These  chains  can  be  arbitrarily  deep,  as  long  as  each  Role 
pointed  to  is  a Role  of  the  V/R  of  the  previous  Role  in  the  chain. 
In  natural  language,  such  a reference  is  expressed  either  as  a 
string  of  "of"  phrases,  or  as  a string  of  possessives,  e.g.,  the 
ARCH's  named After' s name's  lastName. 

Since  SDs  are  inherited  through  the  Concept  taxonomy,  just  as 
Roles  are,  we  need  to  provide  a "decentralized  inheritance" 
mechanism  (see  [Brachman,  1977])  to  allow  some  flexibility.  At  the 
moment,  there  is  only  a single  way  to  relate  an  SD  of  a Concept  to 
one  (or  more)  of  the  SDs  of  its  parent  Concepts.  This  is  the 
"Preempts"  relationship,  and  is  very  simple  - any  SDs  that  would 
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normally  be  inherited  but  that  instead  are  preempted  by  local  SDs 
are  not  considered  to  be  visible.  This  is  similar  to  the  Modifies 
relationship  between  Poles,  although  it  is  a bit  more  severe: 
nothing  from  the  preempted  SD  is  inherited.  At  the  moment,  we  have 
no  insights  on  further  sophistication  of  inter-SD  relationships 
because  it  is  not  clear  how  one  might  use  some  parts  of  an  SD  while 
overriding  others.  We  must  rely  on  the  user  to  maintain  a strict 
subcategorization  hierarchy,  since  this  cannot  be  guaranteed  with 
such  a simple  overriding  mechanism. 

One  further  thing  should  be  noted  here  about  preempting  SDs: 
the  Preempts  links  form  the  inheritance  backbone  for  SDNames.  In 
this  event,  it  is  useful  for  an  SD  to  be  preempted  multiply  at  the 
same  Concept,  so  that  the  multiple  preempting  SDs  can  be  considered 
"subSDs"  of  the  one  they  preempt.  An  exam,  'e  will  serve  to 
illustrate  this. 

In  Concept  C3,  a subConcept  of  both  Cl  and  C2,  we  have  three 
real  SDs  (SI,  S2,  S3),  and  one  inherited  one  (S4)  . SI  and  S2  are 
both  subversions  of  the  "INFER"  SD  of  Cl,  presumably  because  there 
is  some  value  in  modularizing  such  a description.  Meanwhile,  S3 
has  two  parent  SDs,  both  of  which  are  consequently  not  visible  at 
C3.  S3  would  be  considered  both  a "RECOG"  and  a "TEST"  SD. 


8 


Report  No.  4065 


Bolt  Beranek  and  Newman  Inc. 


Fig.  4,  SD  Preempting. 

Finally,  we  have  provided  a simple  mechanism  for  specifying 
when  SDs  are  to  be  "evaluated".  Our  intent  with  the  SD  facility  is 
to  provide  a way  of  declaratively  expressing  constraints  among  the 
fillers  of  a Concept's  Roles.  An  intelligent  interpreter  would 
presumably  know  when  and  how  to  take  advantage  of  such  neutral 
descriptions  of  relationships.  At  the  moment,  however,  the  KLONE 
system  is  not  smart  enough  to  successfully  determine  which  SDs  are 
-elevant  to  checking  structural  validity,  and  which  might  be  useful 
in  deriving  Role  fillers  that  are  dependent  on  others.  We  have  for 
now  provided  a means  of  telling  the  interpreter  directly  which  SDs 
(actually,  which  parts  of  SDs)  are  to  be  used  as  predicates  to 
check  the  satisfaction  of  a generic  description  by  an  Individual 
Concept  and  which  are  to  be  used  as  functions  in  deriving  values 
that  are  determined  by  Role  fillers  previously  specified. 


- 9 - 
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The  mechanism  is  a simple  one:  one  can  specify  for  any 
Paralndiv id ual  that  it  is  to  be  included  in  the  Check,  Derive,  or 
NonActive  "facet"  of  its  SD.  This  will  support  predicative  and 
functional  uses  of  SDs  in  this  manner:  all  Para Ind iv id ual s 

considered  to  be  "Checks"  are  evaluated  at  individuation  time. 
Individuators  of  those  Concepts,  with  the  appropriate  Role 

bindings,  are  searched  for,  and  if  found,  the  Check  is  considered 
*o  succeed.  "Deriving"  Para  Ind  iv  id  ual  s will  then  be  used  to 

determine  fillers  for  Roles  of  the  Individual  Concept  that  can  be 
derived  from  the  fillers  of  other  roles.  Individuators 
corresponding  to  the  "Derive"  Paralndiv  iduals  are  searched  for  (or 
"calculated",  in  a case  like  SUM  or  DISTANCE),  where  matches  are 
attempted  on  all  Roles  except  for  those  pointed  to  by  CorefVal 
links  that  are  considered  Derivable.  Those  Roles  are  filled  in  by 
the  corresponding  values  of  the  Individuator  found  in  the  Search. 

All  Para  Ind  iv  id  uals  not  explicitly  marked  for  checking  or 

deriving  are  considered  "NonActive",  and  are  only  used  either 

subordinately  in  checking  or  deriving  (on  "demand"  by  other 
Paralndiv iduals,  e .g . , a Para Ind iv idual  for  DISTANCE  would  be 
NonActive  if  "used"  by  another  Para  Ind  ividual  for  L-QUAREROOT,  if 
what  was  being  derived  was  the  squareroot  of  the  distance),  or  for 
inference  and  searching  purposes. 
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II.  Function  Descriptions 

In  this  section,  we  present  a description  of  the  set  of 
functions  now  available  in  KLONE  for  manipulating  SDs.  Where 
relevant,  we  note  changes  or  additions  to  the  version  of  KLONE 
described  in  BBN  Report  No.  3848.  The  function  descriptions  start 
with  the  function  name  and  an  argument  list,  and  then  detail  the 
types  and  meanings  of  the  arguments.  Finally,  there  appears  a 
prose  description  of  what  the  function  does. 

First,  we  present  an  indexed  list  of  all  of  the  function  names 
in  alphabetical  order.  The  function  descriptions  follow,  grouped 
roughly  by  type  of  action  they  perform. 


SD  FUNCTION  DESCRIPTIONS 


KLAddParalndividual 20 

KLAddSD 18 

KLAddSDName 19 

KLChangeRoleCoref 24 

KLC.hangeSDName 25 

KLChangeSDOfParalndividual 26 

KLCoref  Satisfy  Role 21 

KLDisEstablishAsPreemptor 33 

KLDisEstablishAsSDFacet 29 

KLEstablishAsPreemptcr 23 

KLEstablishAsSDCheck 27 

KLEstablishAsSDDerive 28 

KLFindAllCoref Roles 13 

KLFindCorefSatisfiersOfRole 1 4 

K LF in d Named  Core  f Roles 15 

KLFindNamedSDs 10 

KLFindNamesOfSD 12 

KLFindOneNamedCorefRole 16 

KLFindParalndividuators 11 

KLFindSDs 9 

KLF  in  d Val  ue  For  Core  f In  Individ  ua  tor 17 

KLGetConceptOfSD 1 

KLGetParalndividualsInSD 3 

KLGetRoleCoref 7 

K LG  etRoleCoref  In  verses 8 

KLGet  SDChec  ks 4 

K LG  etSD  Derives 5 

KLGetSDOf  Paralndiv  id  ual 6 

KLGet  SDs 2 

KLPreemptSD 22 

KLRemoveParalndividual 32 

KLRemoveSD 30 

KLRemoveSDName  31 

KLSDP 34 
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KLGetConceptOfSD  [SD] 


(1) 


description: 

parameters: 
value : 


Returns  the  Concept  of  which  SD  is  an  SD.  An  SD  is  an 
immediate  part  ot  only  one  Concept. 


SD 


type: 

type: 


a single  SD. 
a single  Concept . 


KLGetSDs  [Concept] 
description: 

parameters : 
value: 


(2) 


Retrieves  the  set  of  SDs  immediately  encompassed  by 
Concept.  Does  not  do  inheritance. 


Concept  type : 

type: 


a single  Concept, 
a set  of  SDs. 


KLGetParalndividualsInSD  [SD] 

(••  replaces  KLGetParalndividuallnSDContext  ••) 


(3) 


description:  Retrieves  the  set  of  Paralndividuals  occurring  within  a 

given  SD, 


parameters: 

value: 


SD 


type: 

type: 


a single  SD. 

a set  of  Paralndividual  Concepts. 


KLGetSDChecks  [SD] 
description 

parameters : 
value : 


(H> 

Returns  the  list  of  Paralndividuals  in  the  Check  part 
of  an  SD. 


SD 


type: 
type : 


a single  SD. 

either  a set  of 

Paralndividual  Concepts 
or  NIL. 


KLGetSDDerives  [SD] 
description: 


(5) 


Returns  the  list  of  Paralndividuals  in  the  Derive  part 
of  cm  SD. 


parameters : 
value: 


SD  type : 
type: 


a single  SD. 

either  a set  of 

Paralndividual  Concepts 
or  NIL. 


-14- 


KLGetSDOfParalndividual  [Paraindividual] 

description:  Finds  the  SD  in  which  a particular  Paraindividual 

Concept  is  situated.  The  SD  ic  unique  for  a given 
Paraindividual. 

parameters:  Paraindividual  type:  a single  Paraindividual 

Concept . 

value:  type:  a single  SD. 


(6) 


KLGetRoleCoref  [CorefRole]  (•' 

description:  Given  a Coref  Role,  returns  its  Coref  Value  --  a Role, 

Concept,  or  Paraindividual. 

parameters:  CorefRole  type:  a single  Coref  Role, 

value:  type:  a single  CorefValue. 


KLGetRoleCoref Inverses  [CorefValue] 


(0) 


description:  Retrieves  all  Coref  Roles  to  which  the  value  is  bound 

as  CorefValue. 


parameters:  CorefValue  type: 
r meaning: 


a single  CorefValue. 
the  Concept  or  Role  which  is  the 
CorefValue  of  the  Roles  to  be 
found 


value: 


type: 


either  a set  of 

Coref  Roles 
or  NIL. 


KLFindSDs  [Concept] 

description:  Returns  the  complete  set  of  SDs  applicable  at  a 

Concept. 

parameters:  Concept  type:  a single  Concept, 

value:  type:  a set  of  SDs. 


KLFindNamedSDs  [Concept :SDName] 
(••  new  function 


(10) 


description:  Finds  all  inherited  SDs  at  Concept  that  are  named  by 

SDName . 


parameters : Concept  type : 

SDName  type: 


a single  Concept, 
a single  SDName . 


value : 


type:  a set  of  SDs. 
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KLFindParalndividuators  [GenericConcept]  (11) 

description:  Returns  a list  of  all  of  the  Paralndividuators  of  a 

Concept.  These  include  any  Paralndividuators  of 
SubConcepts  of  the  Concept,  etc. 

parameters:  GenericConcept  type:  a single  Generic  Concept. 

value:  type:  a set  of  Paralndividual 

Concepts. 


KLFindNamesOfSD  [SD] 

(**  new  function  •*) 


(12) 


description:  Finds  the  complete  set  of  inherited  names  applying  to 

SD.  All  names  of  preempted  SDs,  as  well  as  a locally 
attached  one,  are  included. 

parameters:  SD  type:  a single  SD. 

value:  type:  a set  of  SDNames. 


KLFindAllCorefRol.es  [Paralndividual]  (13) 

description:  Finds  all  Coref  Roles  inherited  by  Paralndividual. 

parameters:  Paralndividual.  type:  a single  Paralndividual  Concept. 

value:  type:  either  a set  of  Coref  Roles 

or  NIL. 


KLFindCorefSatisfiersOfRole  [Concept :GenericRolel  (14) 

(**  replaces  KLFindCorefSpecializersOfRole  ••) 


description:  Finds  all  of  the  Instance  Roles  inheritable  by  Concept 

considered  to  be  CorefSatisfiers  of  the  one  specified  as 
argument.  Includes  those  down  Role  inheritance  chains. 


parameters: 

Concept 

type : 
meaning: 

GenericRole 

type: 

val ue : 

type : 

a single  Concept, 
the  context  in  which  the  Coref 
Roles  are  to  be  found 
a single  Generic  Role. 

either  a set  of 

Coref  Roles 
or  NIL. 
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KLFindNamedCorefRoles  [Paralndividual ;RoleName] 


(15) 


description:  Finds  all  Coref  Roles  of  Paralndividual  that  are 

considered  to  be  named  by  RoleName. 


parameters:  Paralndividual  type: 

RoleName  type : 


a single  Paralndividual 
Concept . 

a single  RoleName . 


val ue : 


type:  either  a set  of  Coref  Roles 

or  NIL. 


KLFindOneNamedCorefRole  [Paralndividual; RoleName]  (15) 

description:  Finds  the  one  Coref  Role  of  Paralndividual  that  is 

considered  to  be  named  by  RoleName. 


parameters: 

Paralndividual 

type : 

a single  Paralndividual 
Concept . 

RoleName 

type: 

a single  RoleName. 

value : 

type: 

either  a single  Coref 
Role  or  NIL. 

KLFindValueForCoreflnlndividuator  [CorefRole ;IndividualConcept]  ( 17 ) 

(•*  new  function  **) 


description:  Finds  the  value  in  a particular  Individual  Concept 

that  is  indicated  by  a Coref  Role  in  one  of  its  inherited 
SD's.  That  is,  uses  IndividualConcept  as  the  parameter  for 
a Paralndividuator,  and  evaluates  a coreference  in  that 
context . 


parameters:  Coref Role 


type: 

meaning: 


IndividualConcept  type: 


value: 


type: 

meaning: 


a single  Coref  Role, 
some  Coref  Role  in  an 
inherited  SD  of 
Ind  iv  id  ual  Concept 
a single  Individual 
Concept . 

a single  RoleValue. 
the  meaning  of  the 
coreference  in  the 
context  of 
Indiv id ual Concept 


[] 

c 

u- 


STRUCTURE  BUILDING  FUNCTIONS 


KLAddSD  [GenericConcept ;SDName] 


(18) 


description:  Adds  a blank  SD  to  an  existing  Concept. 


parameters:  GenericConcspt  type* 
SDNamefoptional)  type: 

meaning : 


a single  Generic  Concept, 
a single  SDName. 
if  specified , atatched  to 
new  SD 


value: 


type:  a single  SD. 

meaning:  the  new  SD  created  as  a 

part  of  GenericConcept 


KLAddSDName  [SD; SDName 1 
(**  new  function  *•) 


(19) 


description:  Adds  a name  to  an  SD  - an  SD  can  have  only  one  name 

directly  attached  (although  it  can  inherit  others). 


parameters:  SD  type: 

SDName  type: 


a single  SD. 
a single  SDName. 
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(20) 


KLAdd Paralndividual  [SD;ConceptName;GenericConcept ;WiringList) 

description:  Creates  a new  Paralndividual  Concept,  and  places  it 

within  a Structural  Description  of  an  existing  Concept. 
GenerioConcept  is  the  Concept  that  the  new  one 
Paralndividuates,  and  the  wiring  list  specifies  how  each 
of  its  Roles  are  to  be  matched  up  and  filled.  The 
Paralndividual  added  to  the  SD  is  not  considered  initially 
to  be  in  the  Check  or  Derive  parts. 


parameters:  SD 

Concept Name (optional) 

GenerioConcept 

WiringList 


type:  a single  SD. 

meaning:  SD  to  which 

Paralndividual  is 
added 

type:  a single 

ConceptName. 

meaning:  name  of  new 

Paralndividual 

restrictions : ( “ ( KLGetNamedConcept 
ConceptName) ) 

type:  a single  Generic 

Concept . 

meaning:  Concept  being 

Paralndividuated 

type:  a set  of  triples  of 

a Generic  Role,  one 
of  'CorefSatisfies 
or  'Satisfies,  and 
8 V 3l  UG  • 

meaning:  the  set  of  Role-Role 

connections  for 
constructing  the 
Paralndividual' s 
parts 


value: 


type: 

meaning: 


a single 

Paralndividual 
Concept . 

the  newly  created 
Paralndividual 


KLCorefSatisfyRole  [Paralndividual :CorefValue {SuperRole]  (21) 

(**  replaces  KLAddCorefRole  *•) 


description:  *dds  a Coref  Role  to  an  existing  Concept,  expected  to 

be  a Paralndividual.  SuperRole  is  a Role  or  the  Concept 
being  Para Ind i vidua ted , and  CorefValue  is  the  binding  of 
that  Role  in  the  context  of  Paralndividual.  CorefValues 
are  1:  Roles  of  the  Concept  in  whose  SD  the  Paralndividual 
lies,  2:  that  Concept  itself,  which  means  me  — the 
particular  Individual  Concept  that  has  this  SO  inherited 
and  is  invoicing  it.  3s  a Coref  Role  of  some  other 
Paralndividual  in  the  same  SD  as  the  Para Individual , 4: 
some  other  Paralndividual  in  the  same  SD,  5:  a list  of 
Roles  such  that  the  first  is  a Role  of  the  enclosing 
Concept  and  each  thereafter  is  a Role  of  the  V/R  of  the 
preceding  one  — this  is  a Focus/SubFocus  chain. 


parameters:  Paralndividual  type: 

meaning: 

CorefValue  type: 

meaning : 


SuperRole  type: 

meaning : 


a single  Paralndividual 
Concept . 

Concept  to  which  the  new 
Role  is  to  be  added 
a single  CorefValue. 

Source  of  the  value  of  the 
Role  when  an  individuator  is 
finally  constructed.  If  a 
Role,  then  must  be  of  the 
Concept  in  whose  SD 
Paralndividual  appears,  or  a 
Role  of  another 
Paralndividual  in  the  same 
SD;  if  a Concept,  must  be 
another  Paralndividual,  in 
same  SD  as  Paralndividual, 
or  the  enclosing  Concept 
itself:  if  a list,  must  be  a 
list  of  Roles  accessible  by 
walking  down  Roles  from  the 
enclosing  Concept  --  i.e., 
Focus/SudFocus 
a single  Generic  Role. 

Role  that  is  being 
CorefSatisfied 


value: 


type:  a single  Coref  Role, 

meaning:  the  new  Coref  Role  that  is 

created  as  part  of 
Paralndividual 


KLPreemptSD  [GenericConcept ;SD;SDName] 


(22) 


description: 


Adds  a new  SD  to  GenericConcept  that  will  override  SD, 
whereas  SD  would  normally  be  expected  to  be  inherited 
directly  by  GenericConcept.  SDName  is  an  optional  name  to 
be  attached  to  the  new  SD. 


parameters:  GenerioConcept 

type-: 
meaning : 

SD 

type: 

meaning: 

SDNametoptionall 

type: 

a single  Generic  Concept, 
a Concept  that  would 
normally  inherit  SD,  if  it 
weren't  preempted 
a single  SD. 
the  SD  being  preempted 
a single  SDName. 


val ue : 


type:  a single  SD. 

meaning:  the  new  SD  added  to 

GenericConcept 


KLEstablishAsPreemptor  [PreemptlngSD ;SuperSD] 


(23) 


description: 


parameters : 


Establishes  a relationship  between  two  SD’s  wherein 
one  (the  ProemptingSD)  overrides  the  other.  SuperSD  would 
normally  be  inherited  intact  by  the  Concept  in  which 
PreemptlngSD  appears,  but  ceases  to  have  effect  after  tne 
establishing. 


PreemptlngSD  type: 

meaning : 

SuperSD  type: 

meaning: 


a single  SD. 

the  SD  that  will  override  an 
inherited  one 
a single  SD. 

the  SD  that  will  no  longer  be 
in  effect 


CHANGING  FUNCTICTS 


KLChangeRoleCoref 

description: 


parameters: 


value : 


[Coref Role ;NewCoref Value] 


(24) 


Deletes  the  old  CorefValue  of  a Coref  Role 
replaces  it  witn  a new  one.  Does  not  activate 
Add  IHooks. 


, and 
Delete  or 


CorefRole  type: 

NewCorefValue  type: 

type : 
meaning: 


a single  Coref  Role, 
a single  CorefValue. 

a single  CorefValue. 

the  CorefValue  of  Role  after 

the  change 


KLChangeSDName  [SD;NewSDName] 
(•*  new  function  **) 


(25) 


description:  Removes  old  name  attached  to  SD  and  replaces  it  with 

NewSDName. 


parameters:  SD  type: 

NewSDName  type: 


a single  SD. 
a single  SDName. 
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KLChangeSDOf Paralndi v id ual 
(*■  new  function  **) 


[Paralndividual ;NewSD] 


(26) 


Ascription:  This  function  allows  a Paralndividual  to  be 

transferred  from  one  SD  to  another.  The  SDs  must  be  of  the 
same  Concept,  and  no  CorefRole  of  the  Paralndividual  can 
point  to  anything  within  any  SD  except  the  new  one. 


parameters:  Paralndividual  type: 

NewSD  type: 


a single  Paralndividual 
Concept . 
a single  SD. 


SD  CHECK/DERIVE  FUNCTIONS 


KLEstablishAsSDCheck  [Paralndividual]  (27) 

description:  Takes  a Paralndividual  that  is  part  of  an  SD  and  puts 

it  in  the  Check  part  of  that  SD,  so  that  it  will  be  used 
as  a predicate  when  the  enclosing  Concept  is  individuated. 

parameters:  Paralndividual  type:  a single  Paralndividual 

Concept. 


KLEstablishAsSDDerive  [Paralndividual]  (23) 

description:  Takes  a Paralndividual  that  is  part  of  an  SD  and  puts 

it  in  the  Derive  part  of  that  SD,  so  that  it  will  be  used 
as  a function  to  derive  new  Role  fillers  when  the 
enclosing  Concept  is  individuated. 

parameters:  Paralndividual  type:  a single  Paralndividual 

Concept . 


KLDisEstablishAsSDFacet  [Paralndividual]  (29) 

(**  replaces  KLDicEstablishAsSDCheck  and 

KLDisEstablishAsSDDerive  °*) 


description:  Removes  a Paralndividual  from  either  the  Check  or 

Derive  part  of  an  SD.  Leaves  the  Paralndividual  as  part  of 
the  SD. 


parameters:  Paralndividual  type: 


a single  Paralndividual 
Concept . 
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REMOVING/DELETING  FUNCTIONS 

KLRemoveSD  [SD]  (30) 

description:  Removes  an  SD  from  a Concept,  throwing  away  any 

Paralndividuals  that  it  comprises. 

parameters:  SD  type:  a single  SD. 


KLRemov'eSDName  [SD]  (3D 

(**  new  function  **) 

description:  Removes  any  name  attached  to  an  SD  - does  not  affect 

inherited  names. 

parameters:  SD  type:  a single  SD. 


KLRemoveParalndividual  [Paralndividual]  (32) 

description:  Removes  a Paralndividual  from  an  SD,  and  throws  away 

all  of  its  connections  to  parts  of  the  Concept  it  was  in. 

parameters:  Paralndividual  type:  a single  Paralndividual 

Concept. 


KLDisEstablishAsPreemptor  [SD]  (33) 

description:  Removes  the  preemptive  relationship  between  SD  and  an 

SD  of  a SuperConcept,  wherein  SD  had  previously  overridden 
the  one  in  the  SuperConcept.  The  SD  that  was  previously 
preempted  will  now  be  inherited  intact  by  the  Concept  in 
which  SD  appears. 

parameters:  SD  type:  a single  SD. 

meaning:  an  SD  that  will  no  longer  preempt  one 

inherited  from  a SuperConcept  of  its 
enclosing  Concept . 


OTHER  FUNCTIONS 


KLSDP  [Anything] 


(34) 


description: 

parameters: 


Predicate  to  test  whether  an  item  is  an  SD.  If  so,  the 
item  is  returned;  if  not,  NIL  is  returned. 

Anything  type:  anything. 


value : 


type:  either  NIL  or  a SD. 

meaning:  if  non-NIL,  returns  the  SD  passed 

in  as  argument 


■ -rr : *li 
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